\chapter{Introduction}

\section{Document purpose} 
This document is the documentation for the Mobile Applications module project and therefore part of the module assessment.
The document supplies the lecturer with information about the project development and solution explanations.

\section{Document correlation}
The project documentation document and the project proposal document relate to each other.

\chapter{General description}  


\section{Application summary}
The main goal of the project is the porting of the card game `Pairs' for \acs{Android} Smartphone and 
the implementation of the relevant game rules and procedures.
Two users can select different Pairs games from a list and play with each other on the same Smartphone device.
The application logs information about the recent game, such as the game name, geographical data, time and date.
The user can adjust the difficulty of each game, by changing the amount of cards used for the next game.

During the entire development process, the focus of this project is to acquire practice with programming for Android.

\section{Development environment}
To accomplish the android \acs{app} project, the integrated development environment Eclipse version 4.3 and 
the \acs{ADT} (Android Development Tools) plugin is used. 
The use of Eclipse is not the only possibility \cite{AndroidStudio14IDE}, but the one that is used during the lecture and
therefore best for support issues.

The software versioning and revision control system, \acs{SVN} (Apache Subversion) is used with a \acs{Google Code} repository.

The \acs{app} is tested on the \acs{LG} Nexus 5 \cite{Hardware14Nexus5} 
with the operating system Android 4.4 KitKat (\acs{API} level 19 \cite{KitKatApi14ApiLevel}) and the \acs{ADT} virtual device. 
JUnit tests are not part of the \acs{app} development process.



\chapter{Software architecture and design}
The following explanations and figures refer to the software architecture and design of the android project.

\section{Packet structure}
The packet structure of the project is based on the \acs{MVC} design pattern. 
There are two packages, one packet for all controller classes and one packet for the two data model classes.
The \acs{XML} files for the views are located in the default folder `res\textbackslash layout' and `res\textbackslash layout-land'.


\section{Class diagram}
The figure \ref{fig:ClassDiagram} depicts the class structure of the software project.
Each class is subdivided to its category within the MVC (model-view-controller) software architectural pattern and 
therefore located in different packages.
The figure \ref{fig:ClassDiagram} represents the subdivision into different packages by dashed lines.

The model-view-controller software architecture pattern is convenient for implementing user interfaces.
The pattern organises the application into three interconnected parts, to separate the program logic from the user interface.
The aim of the pattern is the reusability of software components and a flexible software design, 
where it is possible to change the data model independently of the user interface. \cite{DesignPattern14MVC}

The classes \textit{GameList.java} and \textit{Game.java} represent the \textit{model} part of the design pattern.
All \textit{.xml} files contain the basic layout. These files represent the \textit{view} part. 
The activity and adapter classes provide the connection of the model with the view and therefore represent the \textit{controller} part.


\begin{figure}[htbp] 
  \centering 
    \includegraphics[width=15cm]{chapter1/classdiagram}
    \caption{Class diagram created with Eclipse plugin `ObjectAid' \cite{EclipsePlugin14ObjectAid}}
    \label{fig:ClassDiagram}
\end{figure}

\subsection{Data model}
The class `Game' contains the data for one game.
The data for one game includes the game name, the date and the time of the last match, 
the geographical information and a list of image resource references.
The image resource references represent the card set of this particular game.
The class `GameList' contains a list of all games.
The class also includes the file name for data storage and the reference index of the last played game.
Both classes only act as data storage.

\subsection{Controller}
The project contains four controller activities (SplashFullScreenActivity, GameListActivity, 
DetailActivity and GameActivity).
The starting point of the application is the SplashFullScreenActivity, 
while the GameListActivity controls the game selection of the user.
After the selection of a game, the DetailActivity provides the user with some more information and settings about the game. 
During the actual game, the GameActivity regulates the game procedure and user interaction with the dynamic cards set components.
The communication and data exchange between activities is realised by the use of explicit intents (see figure \ref{fig:ClassDiagram}). 
Explicit intents allow to call a special activity or service and to append some simple data types. \cite{Intent14Explicit}
The figure \ref{fig:ClassDiagram} implies the communication flow between the different activities by blue arrows. 

\subsection{View}
The layouts of the different views are defined in the according \acs{XML} files.
Most controls of the user interface are passive elements, which are only used to display some static information.
Section \ref{sec:GUI} describes the different layouts in more detail.


\section{External libraries}
The only external library used for this project is the open source Java library `Google Gson'.
The Gson library is for converting java objects from (and to) \acs{JSON} strings.
The library resides in the project location `libs/gson-2.2.4.jar' and is used for persistent storage of \acs{app} user data
(see chapter \ref{sec:DataStorage} for more detail).
\cite{Google14Gson}
  

\chapter{Technical report}
The following sections describe the main functional blocks of the application 
to provide a basic understanding of the technologies used. 
The blocks are based on the marking scheme of the `Mobile Applications' module handbook, 
with some few additional focus points.



\section{Graphical user interface (\acs{GUI})}
\label{sec:GUI}
This section describes the structure of the different views in detail.
The views use a wide range of techniques to enable the programmer to gain practice with different problem-solving approaches.
Some of the techniques that are used are dialogs, full screen / normal activities, landscape orientation, 
different layouts and a wide range of views.
All views are described in the order of call up.


\subsection{Welcome screen}
In the Android app archive, the Pairs app is represented by the game icon (see figure \ref{fig:ArchiveNexus5}).
After the user clicks the icon, the app starts with the \textit{welcome screen} (see figure \ref{fig:WelcomeScreen}). 
This view informs the user about the game, contains the Pairs game logo and 
prompts the user to touch the screen with two fingers to continue.

The structure of the view is fairly simple and is based on the \textit{RelativeLayout}.
The layout contains four views, three \textit{ImageView} to display the game icon/hints 
and one \textit{TextView} to prompt the user.
Two views are arranged below each other and are centered horizontally (see figure \ref{fig:WelcomeScreen}).
The view to welcome the user is defined for full screen mode in the manifest file, 
as is done by many other popular games \cite{GooglePlay14AngryBirds}.
To start a layout in full screen mode means there is more screen space for the app content.
In full screen mode there is no action bar with the name of the activity and no system bars \cite{AndroidDeveloper14FullScreen}.

\begin{figure}[htbp]
  \centering
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/archiveNexus5}
    \caption{Apps archive with Pairs app icon}
    \label{fig:ArchiveNexus5}
  \end{subfigure}% 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/welcomeScreenStructure}
    \caption{Structure of the welcome screen}
    \label{fig:WelcomeScreenStructure} 
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.27\textwidth}
    \includegraphics[width=\textwidth]{chapter1/welcomeScreen}
    \caption{Screenshot of the welcome screen}
    \label{fig:WelcomeScreen} 
  \end{subfigure}
  \caption{Comparison of the \textit{welcome screen} icon, structure and result}
  \label{fig:welcomeScreenCompare}
\end{figure}


\subsection{Game list}
After the user has confirmed the \textit{welcome screen} to proceed, 
the app changes to the representation of all games (see figure \ref{fig:gameListCompare}).
The list entries provide a one card preview of the card set, the game name and information about the last recent match.
The user can select games with a click on the according list entry.
If the user selects a game, the app changes to a more detailed view.
To see all games, the user can scroll the list.

\begin{figure}[htbp]
  \centering
  \begin{subfigure}[b]{0.26\textwidth}
    \includegraphics[width=\textwidth]{chapter1/mockUpGameListView}
    \caption{Mockup of the game list}
    \label{fig:MockUpGameListview}
  \end{subfigure}% 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.26\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameList}
    \caption{Structure of the list / row}
    \label{fig:gameListStructure} 
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.26\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameListNexus5}
    \caption{Screenshot of the game list }
    \label{fig:gameListNexus5} 
  \end{subfigure}
  \caption{Comparison of the game list mockup, structure and result}
  \label{fig:gameListCompare}
\end{figure}

The structure of the view is a combination of the \textit{LinearLayout} with a \textit{ListView} for all the games and
a \textit{RelativeLayout} with one \textit{ImageView} and two \textit{TextViews} to describe the game list entry
(see figure \ref{fig:gameListStructure}).
The nesting of the layouts is necessary to customize the \textit{ListView} to display more information in a structured manner.
A special adapter class allows the access to single list entry view components.

% - Linearlayout beschreiben: Was es macht und warum es hier so gut passt


\subsection{Game details}
The detail view for one game (see figure \ref{fig:gameDetailsCompare}) 
provides the user with more information about the game. 
In this context, more information means, insight to the entire card set of this game, 
advice about the amount of cards in the set and the time of the last game.
The title bar contains the name of the game.
If there are to many item in the set to fit the screen, the user can scroll to the hidden cards.
This view also enables the user to review the location of the last game within \acs{Google Maps}, 
whether there is geographical data and Internet connection available.
To start a game, the user can fit the amount of cards to his needs, 
by adjusting the seek bar and clicking the `Play' button to change to the gameboard view.

\begin{figure}[htbp]
  \centering
  \begin{subfigure}[b]{0.245\textwidth}
    \includegraphics[width=\textwidth]{chapter1/mockUpDetailView}
    \caption{Mockup of the game details}
    \label{fig:MockUpDetailView} 
  \end{subfigure}% 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.275\textwidth}
    \includegraphics[width=\textwidth]{chapter1/detailView}
    \caption{Structure of the landscape/portrait layout}
    \label{fig:detailViewStructure} 
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.275\textwidth}
    \includegraphics[width=\textwidth]{chapter1/detailviewNexus5}
    \caption{Screenshot in landscape/portrait mode}
    \label{fig:detailviewtNexus5}
  \end{subfigure}
  \caption{Comparison of the game details mockup, structure and result}
  \label{fig:gameDetailsCompare}
\end{figure}

The structure of the view is fairly simple and is based on the \textit{RelativeLayout}.
The layout contains \textit{TextViews}, \textit{Buttons}, a \textit{GridView} and a \textit{SeekBar} 
(see figure \ref{fig:detailViewStructure}).
The game details are available in two different designs.
The choice of the underlying design files is based on the orientation of the Smartphone device.
In portrait orientation, all view elements are arranged below each other and 
the layout file \textit{activity\_detail.xml} from \textit{`res/layout'} is used.
In landscape orientation, the \textit{GridView} for the cards is located on the right-hand side and 
the layout file \textit{activity\_detail.xml} from \textit{`res/layout-land'} is used.
With this problem-solving approach, Android itself takes care about the layout changes, 
depending on the orientation, which reduces complexity in the according activity class \cite{AndroidDeveloper14DifferentScreens}.


\subsection{Gameboard}
The view for the gameboard contains the game setup with subsurface cards, 
the initial score of both players and the prompt for one of the players to start (see figure \ref{fig:gameViewNexus5}).
The prompt is depicted by two red arrows on the left side and on the right side of each player's score information.
While the players try to win the game, the gameboard changes. 
More and more card pairs get removed over time, until a dialog announces which player won the game.
The dialog gives a clear ending to the game and makes sure that both players recognise the winner.
One user has to confirm the dialog to return to the game list.

\begin{figure}[htbp]
  \centering
  \begin{subfigure}[b]{0.22\textwidth}
    \includegraphics[width=\textwidth]{chapter1/mockUpGameboard}
    \caption{Mockup of the gameboard}
    \label{fig:MockUpGameboard}
  \end{subfigure}% 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.32\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameboardStructure}
    \caption{Structure of the gameboard with views placeholder}
    \label{fig:gameboardStructure} 
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameViewNexus5}
    \caption{Screenshot of the gameboard}
    \label{fig:gameViewNexus5}
  \end{subfigure}
  \caption{Comparison of the gameboard mockup, structure and result}
  \label{fig:gameViewCompare}
\end{figure}

The structure of the view is a combination of the \textit{RelativeLayout} and the \textit{GridLayout}
(see figure \ref{fig:gameboardStructure}).
The \textit{GridLayout} holds the cards of the set, 
while the \textit{RelativeLayout} contains the \textit{GridLayout} and some regular view elements.
The gameboard view is defined for full screen mode to have more space for the card set. 
This is important to display them as large as possible and not to waste any screen space for unimportant information.
Each players score information is highlighted on their turns and is aligned to face them.
An animation switches the visibility of the red arrows depending on the game situation.
The manifest file defines this view as portrait oriented view only.
The gameboard view does not need an additional landscape orientated layout, 
because according to the regular game situation described in the proposal document, 
the Smartphone should rest on a flat surface.
Hence, there is no orientation information.
 
With the increase of Smartphone screen size it becomes more interesting 
to develop games like `Pairs' for Smartphone devices (see figure \ref{fig:iPhoneSizeCompare}).
It is more comfortable to play Pairs with its regular card set size on a device with a large screen.

\begin{figure}[htbp] 
  \centering 
    \includegraphics[width=9cm]{chapter1/iPhoneSizeCompare}
    \caption{iPhone size evolution \cite{iPhone14SizeCompare}}
    \label{fig:iPhoneSizeCompare}
\end{figure}


\subsection{Animations}
Animations allow the developer to add a more polished look to their app and catch the users' attention.
With animations it is possible to make games more exciting, by adding some effects on views.
It is important that animations do not disturb the use of the app.
Animations can cause delays of the regular app process and therefore end up disturbing the user. 
\cite{AndroidDeveloper14AddingAnimations}

The Pairs app uses animations to fade in and to fade out some graphics, which inform the players about their turn.
In this particular situation, the animation grabs the attention of the user, 
because the remaining user interface is not animated.


For the Pairs app the animations to fade the views are defined in the files \textit{`fade\_out\_ animation.xml'} 
and  \textit{`fade\_in\_animation.xml'} in the folder \textit{`res/animator'}. 
The XML files describe attributes like the duration, the delay before the animation starts and 
the actual change of the view.
Both files describe an alpha value change to fade in/out from fully opaque to fully transparent and 
vice versa \cite{AndroidDeveloper14AlphaAnimation}.
The GameActivity class loads the animator resources and starts the animation on the respective view.


\section{Game logic}   
The \textit{GameActivity} class realises all the game behaviour of the original game.
At first, in the \textit{onCreate} method a random player gets chosen to start the game, both players scores get set and
the cards of the set get shuffled.
In the next step, all cards of the set are scaled to fit the screen and placed in a random orientation subsurface 
on the gameboard by the method \textit{onGlobalLayout}.
After the game setup is done, the game continues until there are no cards left on the gameboard.
The current player selects the first card to uncover by touch.
The selected card gets revealed.
The current player selects the second card to uncover by touch.
The selected card gets revealed.
If both cards show the same motive, the current player continues to uncover cards and gains one point.
If both cards show a different motive, the cards get covered automatically and thus it becomes the turn of the next player.
The game state is then altered depending on the touch events of the \textit{ImageViews}.
 
The \acs{UML} diagram \ref{fig:gameLogicStateDiagram} below depicts the according state machine.

\begin{figure}[htbp] 
  \centering 
    \includegraphics[width=14cm]{chapter1/gameLogicStateDiagram}
    \caption{Game logic UML state diagram created with `ArgoUML' \cite{ArgoUML14StateDiagram}}
    \label{fig:gameLogicStateDiagram}
\end{figure}


\section{Network resources} 
The Pairs app uses an implicit intent within the \textit{DetailActivity} to start the Google Maps app on some specified 
coordinates and therefore uses network resources.
Implicit intents declare an action to perform, instead of explicit intents that declare the class name of the component to start.
The intent contains data about the latitude and the longitude of the location within the type `Uri'.
The type `Uri' is used as the basis for requesting actions and does just little validation of the input.
Therefore it is important to double check the input for Uri.
\cite{AndroidDeveloper14ImplicitIntent} \cite{AndroidDeveloper14Uri} \cite{webopedia14URIString}
 
After the creation of the intent and the addition of reference data the intent is ready.
Before the intent gets passed to the function \textit{startActivity()}, 
the program checks whether there is at least one app to deal with the requested action specified in the intent.
\cite{AndroidDeveloper14ImplicitIntent}


\section{Multitasking and threading}
\label{sec:Multitasking}
In general, all activities of the same application run in the same process and thread.
This is called the `main' thread.
The execution of an extensive task can block the the main thread and therefore the GUI. 
\cite{AndroidDeveloper14ProcessesAndThreads}

Java and Android provide multiple solutions to do multitasking and threading to solve this issue.
Common options are \textit{Handler}, \textit{Threads}, \textit{Services} and \textit{AsyncTasks}. 
Services are often used for recurring tasks.
Handler and AysncTasks internally use Threads.  
Therefore everything that can be achieved by using one of them, can be achieved by Threads too.
However, Handler and AsyncTasks lighten the workload of the developer. \cite{Stackoverflow14HandlerVsAsyncTask}

The Pairs app uses an AsyncTask within the \textit{GameListActivity} to save changes to the data model.
AsyncTasks perform the blocking operations in a worker thread (function \textit{doInBackground()}) and 
publish the results of the operation on the calling \acs{UI}-thread (function \textit{onPostExecute()}).
The Pairs app needs the function \textit{onPostExecute} only for debugging purposes,
because a GUI update is not necessary.


\section{Data storage and management}
\label{sec:DataStorage}
Android provides different options to store data permanently.
A Shared preferences file is used to store key-value sets for only small amounts of information.
Basic files and the use of an SQLLite database are used to store long sequences of (structured) data.
\cite{AndroidDeveloper14SavingData}

The Pairs app uses a basic file to save data, because it is an easy way to solve the issue of permanent storage of user data.
All objects of the data model get converted to a JSON string and saved to a file of the internal storage.
If the file exists on start up, the app reads the data and converts it back to objects.
If the file does not exist, the app creates the initial data model and saves it.
To convert the objects to (and from) JSON strings, the app uses the external open source Java library `Google Gson'.
The library is integrated in the project and resides in the location `libs\\gson-2.2.4.jar'

The data model contains some information that get changed frequently and some other information that get changed infrequently.
Each time the data model is altered, it gets saved.
It is meaningless to resume to a started Pairs game, as it is a game about remembering the position of cards.
Therefore the current state of the game is not part of the permanent storage.

As already mentioned in section \ref{sec:Multitasking}, the writing process is performed by an \textit{AsyncTask}.


\section{Location detection and sensors}
The Pairs app uses location detection within the \textit{GameActivity} based on \acs{GPS} and Android's Network Location Provider. 
GPS is more precise but quickly consumes battery power, while the Network Location Provider is not very precise but
uses cell tower and Wi-Fi signals which allow location detection indoors and outdoors.
For the Pairs app, the accuracy of the location is not that important, because the information is only to remind the user 
about the rough location of the last game. 
The location is only needed once during the game and can be switched off afterwards.
Therefore it is possible to combine both techniques to get the user location.

To use both techniques, the application must request user permission by declaring 
\textit{ACCESS\_CORASE\_LOCATION} and \textit{ACCESS\_FINE\_LOCATION} in the \textit{manifest} file. 

The first step is to request an instance of system service \textit{LocationManager} from the system.
With the instance of the \textit{LocationManager} it is possible to request location updates.
With the definition of a \textit{LocationListener} it becomes possible to listen to \textit{onLocationChanged}, 
\textit{onProviderEnabled} and \textit{onProviderDisabled} events.
Only the \textit{onLocationChanged} event is important, because the location is not necessary for the
app and only needed once. 
After getting the user location, the \textit{LocationListener} gets removed from the \textit{LocationManager}.
\cite{AndroidDeveloper14Location} \cite{AndroidDeveloper14LocationStrategies}


\section{Gestures}
Gestures are when the user positions his/her fingers on the Smartphone touch screen to do something and 
the app interprets that pattern of touches.
Android provides a wide range of gestures to increase usefulness and appeal of apps.

The Pairs app does not require special gestures, but contains a multi-touch gesture for the 
\textit{welcome screen} to meet the rating criteria mentioned in the module handbook.
The gesture waits until the user puts the required number of fingers on the screen to continue to the game list.
The app detects the number of fingers by checking for the `PointerCount' of the \textit{MotionEvent} in the 
\textit{onTouchEvent()} function.

\section{Languages}
The Pairs app uses the standard solution to supply multi-language support.
The app provides the language `German' and the default language `English'.


\section{Additional features} 
The \textit{GameActivity} class is responsible for the cards setup to start the game.
To do so, it is important to use as much screen space as accessible to show the cards on the gameboard.
Unfortunately, the remaining space for a particular view is unknown in the \textit{onCreate()} method of the activity.
\cite{AndroidDeveloper14ViewTreeObserver} \cite{Stackoverflow14GetViewWidth}

To solve the problem and use as much space as possible, the \textit{GameActivity} class implements the 
\textit{OnGlobalLayoutListener} and listens for \textit{onGlobalLayout} events.
To calculate the size for one card, 
the function calculates $\sqrt{cardAmount}$ to decide whether to arrange the set in a square or a rectangle shape.
If $\sqrt{cardAmount} \notin \mathbb N$ then there is an odd number of columns and rows for the gameboard, 
otherwise they are the same.

The next step is to use the now known size of the \textit{GridLayout} to calculate the size of one quadratic card.
Therefore the sides of the square is the size of the \textit{GridLaout} height or width divided by the amount of cards per row or
column.

After the calculation it is possible to load the images for the \textit{ImageViews} and include them into the \textit{GridLayout}.

\chapter{User guide}
A regular extensive user manual is uncommon for small Smartphone \acs{app}s.
The Google Play Store offers only a limited space for description, requirements and images.
It is important to provide a short and interesting representation of the app to catch the users' attention.
The following user guide is based on the entry of the game `Angry Birds' in the Google Play Store \cite{GooglePlay14AngryBirds}. 
Therefore the user guide contains the typical information accessible in the app store portals.

\section{Description}
\begin{itshape}
Do you like the game Pairs? 

This app brings the cult classic game from back in the old days to your Android Smartphone device. 
The app's usage is a breeze.
Make a choice between six amazing games with varying motives and difficulty levels.
Simply define the length of the game, by adjusting the amount of cards in a set and grab a friend.
LET'S GO! Compete with another player on the same device, no network connection needed.
After this funny brainteaser the winner is announced fully automatic, to instantly start the revenge.
Also enjoy the cool feature to review the date, time and location of the last recent game.

Interested? Let's give it a try and rediscover the fascinating experience of the game Pairs.
\end{itshape}

\section{Further information}

\begin{table}[htdp]
  \centering
  \label{furtherInformation}
  \begin{tabular}{|l||r|}
    \hline
    \textbf{Updated on:}  & Dec 1, 2014 \\ \hline
    \textbf{Size}  & 3.25M \\ \hline
    \textbf{Version:} & 1.0 \\ \hline
    \textbf{Content rating:} & Low maturity \\ \hline
    \textbf{Required Android version:} & 4.4 \\ \hline
    \textbf{Permissions:} & Internet connection and location requests \\ \hline
    \textbf{Developer:} & Martin Walda  \\ \hline
  \end{tabular}
  \caption[Further information]{Further information about the app}
\end{table}

\begin{figure}[htbp]
  \centering
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/welcomeScreenNexus5}
    \caption{Start the app by using gestures}
    \label{fig:welcome}
  \end{subfigure}% 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameListNexus5}
    \caption{Choose from several games}
    \label{fig:gameList} 
  \end{subfigure} 
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/detailViewNexus5Portrait}
    \caption{Take a closer look on sets}
    \label{fig:detail}
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/locationNexus5}
    \caption{View the location of the last game}
    \label{fig:location} 
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/gameboardScreenshot}
    \caption{Play Pairs with a friend}
    \label{fig:gameboard}
  \end{subfigure}
  ~~~~~~~~~~~~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[b]{0.25\textwidth}
    \includegraphics[width=\textwidth]{chapter1/winnerDialogNexus5}
    \caption{Notification of the winner}
    \label{fig:dialog}
  \end{subfigure}
  \caption{App preview screens}
  \label{fig:AppPreview}
\end{figure}


\chapter{Usability and evaluations}
The Pairs app for Android is an easy to use Smartphone application. 

All parts of the app are self-explanatory or contain some hints, to guide and support the user.
The GUI uses the default control elements and is structured in a common way, 
therefore the user does not have to familiarise her/himself completely new.
The app cycle is very linear and contains only a few different screens 
to reduce the acclimatisation period.
Despite the use of animations, the app remains simple to use and 
provides a smooth game experience with no disturbing delays.
The automated game cycle makes the game process more comfortable and keeps the game fair.
The feature to adjust the level of difficulty opens it up to a wide range of potential users.
Also children starting from the age of ten can use the app.

In summary the app can compete with other free Pairs game apps on the Google Play Store. 


\chapter{Conclusions and reflection}
The resulting Pairs apps is a solid game for Android Smartphones that meets the requirements
of the users (mentioned in the proposal).

The development of the game Pairs for Android turns out to be a good possibility to gain practice with basic techniques 
and to test some more advanced features within a reasonable app. 
The focus of this project is on learning new skills in matters of Android programming.
Because of the broad requirements of the module handbook, the optional feature mentioned in the
proposal is not part of the project. 
It is not realistic to do a larger function volume for this app,  
because a large amount of work goes testing, debugging and the finishing of the app.
Therefore additional features, new ideas and enhancements on the current app can be part of further development.

The project was very successful.

